What you need before you begin
Before you begin to implement ELA on the system, you must have the following information available:
An available Class of Service (COS) number. This COS number is used by ELA for list mailboxes and the shadow mailbox. Avaya recommends that you use COS 8.
A community ID for the shadow mailbox. Ideally, the shadow mailbox, as well as the shadow mailboxes of other networked machines, is the only occupant of the selected community. Avaya recommends that you use community 11.
A community ID for the ELA list mailboxes. All the list mailboxes should reside in the same community. This community cannot be the same number as the shadow mailbox community. Avaya recommends that you use community 10.
A range of extensions to use for list mailboxes. You do not need this to set up ELA but you need them to provide extensions for the list mailboxes when you begin creating lists.
Scheduling ELA message delivery
Avaya recommends that you schedule delivery for large enhanced lists during off-peak hours. During peak traffic hours, system processes other subscriber-generated messages on priority and slows down delivery of messages to large enhanced lists.
Local area networks
If your configuration includes a local area network, involve your LAN administrators in the ELA implementation to ensure that the system and the network are not adversely affected. The amount of traffic on your LAN from ELA messages could increase if ELA sends messages for delivery to email or to TCP/IP-networked remote machines. If none of these are valid for your site, ELA does not cause any increase in LAN traffic.
Remote messages
If your site is networked, estimate the increase in the amount of remote traffic by determining the percentage of current traffic that is remote and by calculating the number of messages per minute that percentage represents. When ELA is actively sending messages, add that number of messages to the traffic estimate for remote message delivery.
Call answer messages
ELA lists can also be used to distribute call answer messages. So, anyone can simply call the ELA list mailbox and leave a message. The system then distributes this message to all subscribers in the list. To receive a call answer message, you must administer the ELA mailbox number as an extension on the switch and set the call coverage path to the message server hunt group.
Nested lists
One ELA list can contain another ELA list. For example, you can create ELAlist1 and make ELAlist2 as one of its members. This nesting automatically includes the members of ELAlist2 in ELAlist1. Including a nested list in this example results in only one member (ELAlist2) counting against the ELA list member limit of 1500.
Note A nested ELA list cannot include the ELA list in which it is nested. For example, if ELAlist2 is nested inside of ELAlist1, then ELAlist2 cannot include ELAlist1. The system displays an error if you try to nest a list in this way. However, if you include a non-ELA list within an ELA list, the system cannot check that the non-ELA list also includes the ELA list. If you include a non-ELA list within an ELA list, the system may get into an infinite loop of sending messages, which may cause your subscribers to receive multiple messages.
Shadow mailbox
The shadow mailbox is a special mailbox that ELA uses to distribute messages. You can administer enhanced lists through the Permit Reply field on the Create a New Enhanced-List page so that recipients can reply to the person who originally sent the message and to all recipients of the original message. You can also administer the Permit Reply field so that recipients cannot reply. A properly-configured ELA shadow mailbox helps the system block recipients from replying to ELA senders or recipient lists. The shadow mailbox must belong to a community that cannot receive messages, but can send messages to all other communities.